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1. Introduction 


This document specifies extensions to the IETF TRILL (Transparent 
Interconnection of Lots of Links) protocol [RFC6325] [RFC7177] 
[RFC7780] to support multi-topology routing for both unicast and 
multi-destination traffic based on IS-IS (Intermediate System to 
Intermediate System) [IS-IS] multi-topology [RFC5120]. 
Implementation and use of multi-topology are optional, and use 
requires configuration. It is anticipated that not all TRILL 
campuses will need or use multi-topology. 
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Multi-topology creates different topologies or subsets from a single 
physical TRILL campus topology. This is different from Data Labels 
(VLANs and Fine-Grained Labels (FGLs) [RFC7172]). Data Labels 
Specify communities of end stations and can be viewed as creating 
virtual topologies of end station connectivity. However, in a single 
topology TRILL campus, TRILL Data packets can use any part of the 
physical topology of TRILL switches and links between TRILL switches, 
regardless of the Data Label of that packet's payload. In a multi- 
topology TRILL campus, TRILL data packets in a topology are 
restricted to the TRILL switches and links that are in their 
topology, regardless of the Data Label of their payload. 


The essence of multi-topology behavior is that a multi-topology 
router classifies packets as to the topology within which they should 
be routed and uses logically different routing tables for different 
topologies. If routers in the network do not agree on the topology 
classification of packets or links, persistent routing loops can 
occur. It is the responsibility of the network manager to 
consistently configure multi-topology to avoid such routing loops. 


The multi-topology TRILL extensions can be used for a wide variety of 
purposes, such as maintaining separate routing domains for isolated 
multicast or IPv6 islands, routing a class of traffic so that it 
avoids certain TRILL switches that lack some characteristic needed by 
that traffic, or making a class of traffic avoid certain links due to 
security, reliability, or other concerns. 


It is possible for a particular topology to not be fully connected, 
either intentionally or due to node or link failures or incorrect 
configuration. This results in two or more islands of that topology 
that cannot communicate. In such a case, end stations connected in 
that topology to different islands will be unable to communicate with 
each other. 


Multi-topology TRILL supports regions of topology-ignorant TRILL 
Switches as part of a multi-topology campus; however, such regions 
can only ingress to, egress from, or transit TRILL Data packets in 
the special base topology zero. 
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1.1. Terminology 


The terminology and abbreviations of [RFC6325] are used in this 
document. Some of these are paraphrased below for convenience. Some 
additional terms are also listed. 


campus: The name for a TRILL network, like "bridged LAN" is a name 
for a bridged network. It does not have any academic 
implication. 

DRB: Designated RBridge [RFC7177]. 

FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained 
Label [RFC7172]. By implication, an "FGL TRILL switch" does 
not support Multi-Topology (MT). 


IS: Intermediate System [IS-IS]. 


LSP: Link State PDU (Protocol Data Unit) [IS-IS]. For TRILL, this 
includes Level 1 LSPs and Extended Level 1 Flooding Scope LSPs 
[RFC7780]. 


MT: Multi-Topology [RFC5120]. 


MT TRILL Switch: A TRILL switch supporting the multi-topology 
feature specified in this document. An MT TRILL switch MUST 
support FGL in the sense that it MUST be FGL safe [RFC7172]. 


RBridge: Routing Bridge; an alternative name for a TRILL switch. 


TRILL: Transparent Interconnection of Lots of Links or Tunneled 
Routing in the Link Layer [RFC6325]. 


TRILL Switch: A device implementing the TRILL protocol.  TRILL 
Switches are Intermediate Systems (routers) [IS-IS]. 


VL: VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172]. By 
implication, a "VL RBridge" or "VL TRILL switch" does not 
support FGL or MT. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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2.  Topologies 


In TRILL multi-topology, a topology is a subset of the TRILL switches 
and of the links between TRILL switches in the TRILL campus.  TRILL 
Data packets are constrained to the subset of switches and links 
corresponding to the packet's topology.  TRILL multi-topology is 
based on IS-IS multi-topology [RFC5120]. See Appendix A for 
differences between TRILL multi-topology and [RFC5120]. 


The zero topology is special, as described in Section 2.1. Sections 
2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and 
TRILL Data packets, respectively. 


2.1. Special Topology Zero 


The zero topology is special as the default base topology. All TRILL 
Switches and links are considered to be in, and MUST support, 
topology zero. Thus, for example, topology zero can be used for 
general TRILL switch access within a campus for management messages, 
Bidirectional Forwarding Detection (BFD) messages [RFC7175], RBridge 
Channel messages [RFC7178], and the like. 


2.2. Links and Multi-Topology 


Multi-topology TRILL switches advertise the topologies for which they 
are willing to send and receive TRILL Data packets on a port by 
listing those topologies in one or more MT TLVs [RFC5120] appearing 
in every TRILL Hello [RFC7177] they send out that port, except that 
they MUST handle topology zero, which it is optional to list. 


A link is usable for TRILL Data packets in non-zero topology T only 
if: 


(1) all TRILL switch ports on the link advertise topology T support 
in their Hellos, and 


(2) if any TRILL switch port on the link requires explicit TRILL Data 
packet topology labeling (see Section 2.4) every other TRILL 
switch port on the link is capable of generating explicit packet 
topology labeling. 
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2.3. TRILL Switches and Multi-Topology 


A TRILL switch advertises the topologies that it supports by listing 
them in one or more MT TLVs [RFC5120] in its LSP, except that it MUST 


support topology zero, which is optional to list. For robust and 
rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment 
zero. 

There is no "MT capability bit". A TRILL switch advertises that it 


is MT capable by advertising in its LSP support for any topology or 
topologies with the MT TLV, even if it just explicitly advertises 
support for topology zero. 


2.4. TRILL Data Packets and Multi-Topology 


The topology of a TRILL Data packet is commonly determined from 
either (1) some field or fields present in the packet itself or (2) 
the port on which the packet was received; however, optional explicit 
topology labeling of TRILL Data packets is also proved. This can be 
included in the data labeling area of TRILL Data packets as specified 
below. 


Examples of fields that might be used to determine topology are 
values or ranges of values of the payload VLAN or FGL [RFC7172], 
packet priority, IP version (IPv6 versus IPv4) or IP protocol, 
Ethertype, unicast versus multi-destination payload, IP 
Differentiated Services Code Point (DSCP) bits, or the like. 


Multi-topology does not apply to TRILL IS-IS packets or to link level 
control frames. Those messages are link local and can be thought of 
as being above all topologies. Multi-topology only applies to TRILL 
Data packets. 
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2.4.1. Explicit Topology Labeling Support 


Support of the topology label is optional. Support could depend on 
port hardware and is indicated by a 2-bit capability field in the 
Port TRILL Version sub-TLV [RFC7176] appearing in the Port 
Capabilities TLV in Hellos. If there is no Port TRILL Capabilities 
sub-TLV in a Hello, then it is assumed that explicit topology 
labeling is not supported on that port. See the table below for the 
meaning of values of the Explicit Topology capability field: 


0 No support. Cannot send TRILL Data packets with an 
explicit topology label and will likely treat as 
erroneous and discard any TRILL Data packet received with 
a topology label. Such a port is assumed to have the 
ability and configuration to correctly classify TRILL 
Data packets into all topologies for which it is 
advertising support in its Hellos, either by examining 
those packets or because they are arriving at that port. 


1 Capable of inserting an explicit topology label in TRILL 
Data packets sent and tolerant of such labels in received 
TRILL Data packets. Such a port is capable, for all of 
the topologies it supports, of determining TRILL Data 
packet topology without an explicit label. Thus, it does 
not require such a label in received TRILL Data packets. 
On receiving a packet whose explicit topology label 
differs from the port's topology determination for that 
packet, the TRILL switch MUST discard the packet. 


2 & 3 Require an explicit topology label in received TRILL Data 
packets except for topology zero. Any TRILL Data packets 
received without such a label are classified as being in 
topology zero. Also capable of inserting an explicit 
topology label in TRILL Data packets sent. (Values 2 and 
3 are treated the same, which is the same as saying that 
if the 2 bit is on, the 1 bit is ignored.) 


In a Hello on Port P, a TRILL switch advertising support for topology 
T but not advertising that it requires explicit topology labeling is 
assumed to have the ability and configuration to correctly classify 
TRILL Data packets into topology T by examination of those TRILL Data 
packets and/or by using the fact that they are arriving at port P. 


When a TRILL switch transmits a TRILL Data packet onto a link, if any 


other TRILL switch on that link requires explicit topology labeling, 
an explicit topology label MUST be included unless the TRILL Data 
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packet is in topology zero, in which case, an explicit topology label 
MAY be included. If a topology label is not so required, but all 
other TRILL switches on that link support explicit topology labeling, 
then such a label MAY be included. 


2.4.2. The Explicit Topology Label 


This section specifies the explicit topology label. Its use by TRILL 
is specified in Section 2.4.3. This label may be used by other 
technologies besides TRILL. The MT Label is structured as follows: 


0 1 2 3 

0 2-34 56 T.9.9-0 1-2. 3 4 5-6- 74:8 9 .05L 2 2 4-56 7:8.9.0-1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| MT Ethertype 0x9A22 | | MT-ID | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 1: MT Label 
Where the fields are as follows: 
MT Ethertype: The MT Label Ethertype (see Section 6.1). 


V: The version number of the MT Label. This document specifies 
version zero. 


R: A 2-bit reserved field that MUST be sent as zero and ignored on 
receipt. 


MT-ID: The 12-bit topology using the topology number space of the MT 
TLV [RFC5120]. 


2.4.3. TRILL Use of the MT Label 


With the addition of the version zero MT Label, the four standardized 
content varieties for the TRILL Data packet data labeling area (the 
area after the Inner.MacSA -- or Flag Word if the Flag Word is 
present [RFC7780] -- and before the payload) are as show below. 

TRILL Data packets received with any other data labeling are 
discarded. (PRI, D) is a 3-bit priority and a drop eligibility 
indicator bit [RFC7780]. 


All MT TRILL switches MUST support FGL, in the sense of being FGL 
safe [RFC7172]; thus, they MUST support all four data labeling area 
contents shown below. (This requirement is imposed, rather than 
having FGL support and MT support be independent, to reduce the 
number of variations in RBridges and simplify testing.) 
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1 
OT 2 33:6 708 9 0 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


FGL = 0x893B 


FGL = 0x893B 


下 
1'.259:4/5.:0: 79 9-0" 1727.3 


| PRI 


| PRI 


3. MT C-VLAN [RFC8377] 
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012345678 90 
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MT Ethertype 
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DD 
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0x9A22 0 | R MT-ID 
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PRI |D| VLAN ID 
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ll ee a ee D 
1234956 78 9 Q 12 3.4 
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0x9A22 | 0 | R MT-ID 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
| PRI | 
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| PRI |D 
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十 
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|D| FGL High Part | 
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Scope of this document, but, as stated in [RFC6325], 
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3. TRILL Multi-Topology Adjacency and Routing 


Routing calculations in IS-IS are based on adjacency. Section 3.1 
specifies multi-topology TRILL adjacency. Section 3.2 describes the 
handling of nicknames. Sections 3.3 and 3.4 specify how unicast and 
multi-destination TRILL multi-topology routing differ from the TRILL 
base protocol routing. 


3.1. Adjacency 


There is no change in the determination or announcement of adjacency 
for topology zero, which is as specified in [RFC7177]. When a 
topology zero adjacency reaches the Report state, as specified in 
[RFC7177], the adjacency is announced in core LSPs using the Extended 
Intermediate System Reachability TLV (#22). This will be compatible 
with any legacy topology-ignorant RBridges that might not support E- 
L1FS FS-LSPs [RFC7780]. 


Adjacency is announced for non-zero topologies in LSPs using the MT 
Reachable Intermediate Systems TLV (#222) as specified in [RFC5120]. 
A TRILL switch reports adjacency for non-zero topology T if and only 
if that adjacency is in the Report state [RFC7177] and the two 
conditions listed in Section 2.2 are true, namely: 


1. All the ports on the link are announcing support of topology T. 


2. If any port announces that it requires explicit topology labeling 
(Explicit Topology capability field value 2 or 3), all other ports 
advertise that they are capable of producing such labeling 
(Explicit Topology capability field value of 1, 2, or 3). 


3.2. TRILL Switch Nicknames 


TRILL switches are usually identified within the TRILL protocol (for 
example, in the TRILL Header) by nicknames [RFC6325] [RFC7780]. Such 
nicknames can be viewed as simply 16-bit abbreviation for a TRILL 
switch’s (or pseudo-node's) 7-byte IS-IS System ID. A TRILL switch 
or pseudo-node can have more than one nickname, each of which 
identifies it. 


Nicknames are common across all topologies, just as IS-IS System IDs 
are. Nicknames are determined as specified in [RFC6325] and 
[RFC7780] using only the Nickname sub-TLVs appearing in Router 
Capabilities TLVs (#242) advertised by TRILL switches. In 
particular, the nickname allocation algorithm ignores Nickname sub- 
TLVs that appear in MT Router Capability TLVs (#144). (However, 
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Nickname sub-TLVs that appear in MT Router Capability TLVs with a 
non-zero topology do affect the choice of distribution tree roots as 
described in Section 3.4.1.) 


To minimize transient inconsistencies, all Nickname sub-TLVs 
advertised by a TRILL switch for a particular nickname, whether in 
Router Capability or MT Router Capability TLVs, SHOULD appear in the 
same LSP PDU. If that is not the case, then all LSP PDUs in which 
they do occur SHOULD be flooded as an atomic action. 


3.3. TRILL Unicast Routing 


TRILL Data packets being TRILL unicast (those with TRILL Header M bit 
= 0) are routed based on the egress nickname using logically separate 
forwarding tables per topology T, where each such table has been 
calculated based on least cost routing within T: that is, only using 
links and nodes that support T. Thus, the next hop when forwarding 
TRILL Data packets is determined by a lookup logically based on 
(topology, egress nickname]. 


3.4. TRILL Multi-Destination Routing 


TRILL sends multi-destination data packets (those packets with TRILL 
Header M bit = 1) over a distribution tree. Trees are designated by 
nicknames that appear in the "egress nickname" field of multi- 
destination TRILL Data packet TRILL Headers. To constrain multi- 
destination packets to a topology T and still distribute them 
properly requires the use of a distribution tree constrained to T. 
Handling such TRILL Data packets and distribution trees in TRILL MT 
is as described in the subsections below. 


3.4.1. Distribution Trees 


General provisions for distribution trees and how those trees are 
determined are as specified in [RFC6325], [RFC7172], and [RFC7780]. 
The distribution trees for topology zero are determined as specified 
in those references and are the same as they would be with topology- 
ignorant TRILL switches. 


The TRILL distribution tree construction and packet handling for some 
non-zero topology T are determined as specified in [RFC6325], 
[RFC7172], and [RFC7780] with the following changes: 


o As specified in [RFC5120], only links usable with topology T 
TRILL Data packets are considered when building a distribution 
tree for topology T. As a result, such trees are automatically 
limited to and separately span every internally connected 
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island of topology T. In other words, if non-zero topology T 
consists of disjoint islands, each distribution tree 
construction for topology T is local to one such island. 


Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub- 
TLV, and Trees Used sub-TLV occurring in an MT Router 
Capabilities TLV (4144) specifying topology T are used in 
determining the tree root(s), if any, for a connected area of 
non-zero topology T. 


+ There may be non-zero topologies with no multi-destination 
traffic or, as described in [RFC5120], even topologies with 
no traffic at all. For example, if only known destination 
unicast IPv6 TRILL Data packets were in topology T and all 
multi-destination IPv6 TRILL Data packets were in some other 
topology, there would be no need for a distribution tree for 
topology T. For this reason, a Number of Trees to Compute 
field value of zero in the Trees sub-TLV for the TRILL 
switch holding the highest priority to be a tree root for a 
non-zero topology T is honored and causes no distribution 
trees to be calculated for non-zero topology T. This is 
different from the base topology zero where, as specified in 
[RFC6325], a zero Number of Trees to Compute field value 
causes one tree to be computed. 


Nicknames are allocated as described in Section 3.2. Ifa 
TRILL switch advertising that it provides topology T service 
holds nickname N, the priority of N to be a tree root is given 
by the tree root priority field of the Nickname sub-TLV that 
has N in its nickname field and occurs in a topology T MT 
Router Capabilities TLV advertised by that TRILL switch. If no 
such Nickname sub-TLV can be found, the priority of N to be a 
tree root is the default for an FGL TRILL switch as specified 
in [RFC7172]. 


+ There could be multiple topology T Nickname sub-TLVs for N 
being advertised for a particular RBridge or pseudo-node, 
due to transient conditions or errors. In that case, any 
advertised in a core LSP PDU are preferred to those 
advertised in an E-L1FS FS-LSP PDU. Within those 
categories, the one in the lowest numbered fragment is used 
and if there are multiple in that fragment, the one with the 
smallest offset from the beginning of the PDU is used. 


Tree pruning for topology T uses only the Interested VLANs sub- 


TLVs and Interested Labels sub-TLVs [RFC7176] advertised in MT 
Router Capabilities TLVs for topology T. 
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An MT TRILL switch MUST have logically separate routing tables per 
topology for the forwarding of multi-destination traffic. 


3.4.2. Multi-Access Links 


Multi-destination TRILL Data packets are forwarded on broadcast 
(multi-access) links in such a way as to be received by all other 
TRILL switch ports on the link. For example, on Ethernet links they 
are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken 
that a TRILL Data packet in a non-zero topology is only forwarded by 
an MT TRILL switch. 


For this reason, a non-zero topology TRILL Data packet MUST NOT be 
forwarded onto a link unless the link meets the requirements 
specified in Section 2.2 for use in that topology even if there are 
one or more MT TRILL switch ports on the link. 


4. Mixed Links 


There might be any combination of MT, FGL, or even VL TRILL switches 
[RFC7172] on a link. DRB (Designated RBridge) election and Forwarder 
appointment on the link work as previously specified in [RFC8139] and 
[RFC7177]. It is up to the network manager to configure and manage 
the TRILL switches on a link so that the desired switch is DRB and 
the desired switch is the Appointed Forwarder for the appropriate 
VLANs. 


Frames ingressed by MT TRILL switches can potentially be in any 
topology recognized by the switch and permitted on the ingress port. 
Frames ingressed by VL or FGL TRILL switches can only be in the base 
zero topology. Because FGL and VL TRILL switches do not understand 
topologies, all occurrences of the following sub-TLVs MUST occur only 
in MT Port Capability TLVs with a zero MT-ID. Any occurrence of 
these sub-TLVs in an MT Port Capability TLV with a nonzero MT-ID is 
ignored. 


Special VLANs and Flags Sub-TLV 
Enabled-VLANs Sub-TLV 
Appointed Forwarders Sub-TLV 
VLANs Appointed Sub-TLV 


Native frames cannot be explicitly labeled (see Section 2.4) as to 
their topology. 
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5. Other Multi-Topology Considerations 
5.1. Address Learning 


The learning of end station Media Access Control (MAC) addresses is 
per topology as well as per label (VLAN or FGL). The same MAC 
address can occur within a TRILL campus for different end stations 
that differ only in topology without confusion. 


5.1.1. Data Plane Learning 


End station MAC addresses learned from ingressing native frames or 
egressing TRILL Data packets are, for MT TRILL switches, qualified by 
topology. That is, either the topology into which that TRILL switch 
classified the ingressed native frame or the topology that the 
egressed TRILL Data frame was in. 


5.1.2. Multi-Topology ESADI 


In an MT TRILL switch, End Station Address Distribution Information 
(ESADI) [RFC7357] operates per label (VLAN or FGL) per topology. 
Since ESADI messages appear, to transit TRILL switches, like normal 
multi-destination TRILL Data packets, ESADI link state databases and 
ESADI protocol operation are per topology as well as per label and 
local to each area of multi-destination TRILL data connectivity for 
that topology. 


5.2. Legacy Stubs 


Areas of topology-ignorant TRILL switches can be connected to and 
become part of an MT TRILL campus but will only be able to ingress 
to, transit, or egress from topology zero TRILL Data packets. 


5.3.  RBridge Channel Messages 


RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175] 
appear, to transit TRILL switches, like normal multi-destination 
TRILL Data packets. Thus, they have a topology and, if that topology 
is non-zero, are constrained by topology like other TRILL Data 
packets. Generally, when sent for network management purposes, they 
are sent in topology zero to avoid such constraint. 
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4. Implementations Considerations 


MT is an optional TRILL switch capability. 


Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120] 
indicates that a single router handling more than eight topologies is 
rare. There may be many more than eight distinct topologies in a 
routed area, such as a TRILL campus; in that case, many of these 
topologies will be handled by disjoint sets of routers and/or links. 


Based on this deployment experience, a TRILL switch capable of 
handling eight or more topologies can be considered a full 
implementation while a TRILL switch capable of handling four 
topologies can be considered a minimal implementation but still 
useful under some circumstances. 

Allocation Considerations 

IEEE Registration Authority and IANA considerations are given below. 


1. IEEE Registration Authority Considerations 


The IEEE Registration Authority has allocated Ethertype 0x9A22 for 
the MT Label (see Section 2.4). 


2. IANA Considerations 


IANA has assigned a field of two adjacent bits (14-15) of the 
Capabilities bits of the Port TRILL Version Sub-TLV for the Explicit 
Topology capability field and updated the "PORT-TRILL-VER Sub-TLV 
Capability Flags" registry as follows. 


Bit Description Reference 


14-15 Topology labeling support. [RFC8377] 
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IANA has created the informational "TRILL Ethertypes" subregistry in 
the "Transparent Interconnection of Lots of Links (TRILL) Parameters" 
registry. 


Name: TRILL Ethertypes 

Registration Procedure(s): Ethertypes are assigned by the IEEE 
Registration Authority. Updates to this registry are coordinated 
with the designated expert. 

Reference: [RFC8377] 


Note: This registry provides centralized documentation of 
Ethertypes that were assigned by the IEEE for initial use 
with TRILL. In some cases, particularly L2-IS-IS and MT, 
they may be used with other protocols. 


Value Mnemonic Explanation Reference 

0x22F3 TRILL TRILL data [RFC6325] 

0x22F4 L2-IS-IS  IS-IS [RFC6325] 

0x893B FGL Fine Grained Labeling  [RFC7172] 

0x8946 = TRILL RBridge Channel  [RFC7178] 

0x9A22 MT Multi-Topology [RFC8377] 
7. Security Considerations 


Multiple topologies are sometimes used for the isolation or security 
of traffic. For example, if some links were more likely than others 
to be subject to adversarial observation, it might be desirable to 
classify certain sensitive traffic in a topology that excluded those 
links. 


Delivery of data originating in one topology outside of that topology 
is generally a security policy violation to be avoided at all 
reasonable costs. Using IS-IS security [RFC5310] on all IS-IS PDUs 
and link security appropriate to the link technology on all links 
involved, particularly those between RBridges, supports the avoidance 
of such violations. 


For general TRILL security considerations, see [RFC6325]. 
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Appendix A. Differences from RFC 5120 


TRILL multi-topology, as specified in this document, differs from RFC 
5120 as follows: 


1. [RFC5120] provides for unicast multi-topology. This document 
extends that to cover multi-destination TRILL data distribution 


(see Section 3.4). 


2. [RFC5120] assumes the topology of data packets is always 
determined implicitly, that is, based on the port over which the 
packets are received and/or preexisting fields within the packet. 
This document supports such implicit determination, but it extends 
this by providing for optional explicit topology labeling of data 
packets (see Section 2.4). 


3. [RFC5120] makes support of the default topology zero optional for 
MT routers and links. For simplicity and ease in network 
management, this document requires all TRILL switches and links 
between TRILL switches to support topology zero (see Section 2.1). 


Acknowledgements 


The comments and contributions of the following are gratefully 
acknowledged: 


Vishwas Manral and Martin Vigoureux 


Eastlake, et al. Standards Track [Page 19] 


RFC 8377 TRILL: Multi-Topology July 2018 


Authors' Addresses 


Donald Eastlake 3rd 
Huawei Technologies 
1424 Pro Shop Court 
Davenport, FL 33896 
United States of America 


Phone: -1-508-333-2270 
Email: d3e3e3@gmail.com 


Mingui Zhang 

Huawei Technologies Co., Ltd. 

HuaWei Building, No.3 Xinxi Rd., Shang-Di 
Information Industry Base, Hai-Dian District, 
Beijing, 100085 

China 


Email: zhangmingui@huawei.com 


Ayan Banerjee 

Cisco 

170 W. Tasman Drive 

San Jose, CA 95134 
United States of America 


Email: ayabaner@cisco.com 


Eastlake, et al. Standards Track [Page 20] 


